Software management system

ABSTRACT

A software management system for processing, maintaining improved reliability, a software delivered on a wide-area network. A center server  1  includes a script  12  describing the operation of the application  11 , and a fault countermeasure means  13  for coping with the occurrence of a fault. A local server  3  includes a network-directed language execution environment  31 , a remote management means  32  for downloading or deleting the application, a script interpretation means  33 , and a highly reliable means  34  for recording event data that occur while the application is being executed, for managing the data when the fault has occurred, and for executing the restoration processing. The system guarantees safe and reliable operation of the software that is downloaded through a wide-area network, and offers a function of supporting the collection of fault data and restoration even in case an abnormal condition has occurred,

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to a software management systemcomprising a network system which includes a center server and a localserver connected to the center server via a wide-area network, such thatthe center server manages the whole wide-area network. Moreparticularly, the invention relates to a software management systemwhich features an improved function for downloading the applicationsoftware from the center server onto the local server maintainingimproved reliability.

[0003] 2. Prior Art

[0004] Use of a wide-area network such as internet is ever spreading inrecent years. Further, the widespread use of “Java” which is anetwork-directed program language, is requiring an increased amount ofprocessing for downloading the softwares from the center server onto alocal server (computer, etc.) via a wide-area network.

[0005] Besides, in recent years, even a computer having a relativelysmall memory capacity, such as a built-in type local server, isrequiring a mechanism for downloading the application software.

[0006] However, the local server of the built-in type having a smallmemory capacity is not often capable of placing all applications on thememory at all times. Besides, the local server of the built-in type hasnot been equipped with an auxiliary storage unit such as disk and must,hence, be equipped with a function for downloading the software asrequired and for deleting the software when it is no longer necessary.

[0007] The above-mentioned remote software management function hasheretofore been standardized under OSG (Open Gateway Service) determinedby, for example, OGSi (Open Gateway Service Initiative)(for details, seeWebsite “http://www.osgi.org/” of OGSi).

[0008] The OSG standard specifies the system for downloading anddeleting the software. When the system requires higher reliability,however, a mechanism must be devised and furnished to guarantee a highlyreliable function and a safe and reliable operation.

[0009] For example, “a network management method and a system therefor”disclosed in Japanese Unexamined Patent Publication (Kokai) No.11-65968) is the one in which a system based on a manager agent modelspecified under “M. 3010” recommended by ITU-T is furnished with amechanism for downloading a software described in Java.

[0010] The network management system described in the above publicationis based on the manager agent model specified under “M. 3010”recommended by ITU-T, but gives no attention to the processing of whenthe operation of the software itself described in Java becomes abnormalor to the contrivance for improving reliability.

[0011] That is, in the conventional remote software management systemsvia the network, the basic functions for downloading and deletion havebeen specified, but no consideration has been given to the functions forimproving the reliability of the system, such as the processing forcoping with the abnormal operation of the software that is downloaded orthe mechanism for guaranteeing safe and reliable operation.

[0012] When a consideration is given to that the softwares may befurther delivered via the network in the future, it needs not be pointedout that it becomes very necessary to maintain safety of the softwarethat is downloaded and to cope with the abnormal operation that mayhappen. However, no conventional system is capable of coping with thedemand to a sufficient degree.

[0013] As described above, the conventional software management systemis capable of neither meeting the requirement for maintaining safety ofthe software that is downloaded nor coping with abnormal operation thatmay happen.

SUMMARY OF THE INVENTION

[0014] The present invention was accomplished in order to solve theabove-mentioned problem, and has the object of providing a functionwhich guarantees safe and reliable operation of the software that isdownloaded through a network, and supports the collection of fault dataand restoration even in case an abnormal condition has occurred, and ofobtaining a software management system for processing, maintainingimproved reliability, a software delivered on a wide-area network.

[0015] A software management system according to the present inventioncomprises a network system which includes a center server and a localserver connected to the center server via a wide-area network, wherein:the center server includes; an application that operates upon beingdownloaded onto the local server; a script describing the operation ofthe application; and a fault countermeasure means for coping with theoccurrence of a fault; and the local server includes: a network-directedlanguage execution environment; a remote management means fordownloading the application from the center server, and for deleting theapplication after the processing has been finished; a scriptinterpretation means for interpreting the script and for requesting theapplication to execute the processing; and a highly reliable means forrecording event data that occur while the application is being executed,for managing the data when the fault has occurred, and for executing therestoration processing.

[0016] In the software management system of the invention, the remotemanagement means includes: center server data and application data; arequest processing means that works in response to a request forexecuting the application; an application downloading means fordownloading the application from the center server based upon the centerserver data and the application data; and an application managementmeans for executing the processing for driving or deleting theapplication based on the application data.

[0017] In the software management system of the invention, the scriptinterpretation means includes: a script definition and a list of events;an interpretation means for interpreting the script in accordance withthe script definition and for outputting an event corresponding to thecontent of definition of the script; and an event drive means forfetching the event and for picking up a processing that is driven by theevent according to the list of events.

[0018] In the software management system of the invention, the script isdescribed in XML (extensible markup language), and the script definitionis described in DTD (document type definition).

[0019] In the software management system of the invention, the faultcountermeasure means includes: a fault data-obtaining means forobtaining fault data from the local server in case fault has occurred;and a fault countermeasure-notifying means for determining thecountermeasure against the fault in case the fault has occurred and fornotifying it to the local server; and the highly reliable meansincludes: a fault detector means for detecting the occurrence of a faultthat has occurred; a fault data correction means for correcting thefault data when the fault has occurred; a fault-notifying means fornotifying the fault data to the center server; a restoration means forrestoring the fault relying upon the countermeasure against the faultfrom the center server; and an event collection means for correcting andrecording the event data.

[0020] In the software management system of the invention, the faultcountermeasure means includes: a list of fault countermeasures, storingcountermeasures against faults for each of the kinds of the fault data;and the fault countermeasure-notifying means includes: a faultcountermeasure detector means for detecting a countermeasure againstfault corresponding to the kind of the fault data based upon a list ofthe fault countermeasures; and a notifying means for notifying thecountermeasure against fault to the local server.

[0021] In the software management system of the invention, the faultcountermeasure means includes: a fault data-obtaining means forobtaining fault data of when the fault has occurred from the localserver; and the highly reliable means includes:

[0022] a fault detector means for detecting the occurrence of a fault; afault data collection means for collecting fault data of when the faulthas occurred; a restoration means for autonomously coping with theoccurrence of a fault to automatically restore the fault; a notifyingmeans for notifying the fault data and the data of automatic restorationto the center server; and an event collection means for collecting andrecording the event data.

[0023] In the software management system of the invention, the localservers exist in a plural number, each of which including thenetwork-directed language execution environment, the remote managementmeans, the script interpretation means and the highly reliable means.

[0024] In the software management system of the invention, the centerservers exist in a plural number, each of which including theapplication, the script and the fault countermeasure means.

[0025] In the software management system of the invention, the localservers exist in a plural number, at least one of which including thenetwork-directed language execution environment, the remote managementmeans, the script interpretation means and the highly reliable means,and other local servers including the network-directed languageexecution environment, the remote management means and the scriptinterpretation means.

[0026] A software management system according to the present inventioncomprises a network system which includes a center server and a localserver connected to the center server via a wide-area network, wherein:the center server includes; an application that operates upon beingdownloaded onto the local server; and a script describing the operationof the application; and the local server includes: a network-directedlanguage execution environment; a remote management means fordownloading the application from the center server, and for deleting theapplication after the processing has been finished; and a scriptinterpretation means for interpreting the script and for requesting theapplication to execute the processing.

[0027] In the software management system of the invention, the localservers exist in a plural number, each of which including thenetwork-directed language execution environment, the remote managementmeans and the script interpretation means.

[0028] A software management system according to the present inventioncomprises a network system which includes a center server and a localserver connected to the center server via a wide-area network, wherein:the center server includes; an application that operates upon beingdownloaded onto the local server; and a fault countermeasure means forcoping with the occurrence of a fault; and the local server includes: anetwork-directed language execution environment; a remote managementmeans for downloading the application from the center server, and fordeleting the application after the processing has been finished; and ahighly reliable means for recording event data that occur while theapplication is being executed, for managing the data when the fault hasoccurred, and for executing the restoration processing.

[0029] In the software management system of the invention, the localservers exist in a plural number, each of which including thenetwork-directed language execution environment, the remote managementmeans and the highly reliable means.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030]FIG. 1 is a block diagram illustrating the constitution of anembodiment 1 of the present invention;

[0031]FIG. 2 is a flowchart illustrating the operation according to theembodiment 1 of the present invention;

[0032]FIG. 3 is a block diagram illustrating the constitution of anembodiment 2 of the present invention;

[0033]FIG. 4 is a flowchart illustrating the operation according to theembodiment 2 of the present invention;

[0034]FIG. 5 is a block diagram illustrating the constitution of a majorportion according to an embodiment 3 of the present invention;

[0035]FIG. 6 is a diagram illustrating a script definition according tothe embodiment 3 of the present invention;

[0036]FIG. 7 is a diagram illustrating a list of events according to theembodiment 3 of the present invention;

[0037]FIG. 8 is a flowchart illustrating the operation according to theembodiment 3 of the present invention;

[0038]FIG. 9 is a diagram illustrating an example of descriptionservices according to an embodiment 4 of the present invention;

[0039]FIG. 10 is a diagram illustrating an example of descriptionservices according to the embodiment 4 of the present invention;

[0040]FIG. 11 is a block diagram illustrating the constitution of anembodiment 5 of the present invention;

[0041]FIG. 12 is a flowchart illustrating the operation according to theembodiment 5 of the present invention;

[0042]FIG. 13 is a block diagram illustrating the constitution of anembodiment 6 of the present invention;

[0043]FIG. 14 is a flowchart illustrating the operation according to theembodiment 6 of the present invention;

[0044]FIG. 15 is a block diagram illustrating the constitution of anembodiment 7 of the present invention;

[0045]FIG. 16 is a flowchart illustrating the operation according to theembodiment 7 of the present invention;

[0046]FIG. 17 is a block diagram illustrating the constitution of anembodiment 8 of the present invention;

[0047]FIG. 18 is a block diagram illustrating the constitution of anembodiment 9 of the present invention;

[0048]FIG. 19 is a block diagram illustrating the constitution of anembodiment 10 of the present invention; and

[0049]FIG. 20 is a block diagram illustrating the constitution of anembodiment 11 of the present invention;

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0050] Embodiment 1.

[0051] An embodiment 1 of the present invention will now be described indetail with reference to the drawings.

[0052]FIG. 1 is a block diagram schematically illustrating theconstitution according to the embodiment 1 of the present invention.

[0053] In FIG. 1, a center server 1 includes an application 11, a script12 describing the operation of the application, and a faultcountermeasure means 13 which copes with the occurrence of a fault.

[0054] As will be described later, the application 11 includes pluralapplications 11 a to 11 x, and the script 12 includes plural scripts 12a to 12 x corresponding to the applications 11 a to 11 x.

[0055] A wide-area network 2 connects the center server 1 to a localserver 3.

[0056] The application 11 in the center server 1 is downloaded onto thelocal server 3 through the wide-area network 2 and is operated.

[0057] The local server 3 includes the applications 11 a to 11 x thatare downloaded from the center server 1 as required, a network-directedlanguage execution environment 31 comprising Java VM, a remotemanagement means 32, a script interpretation means 33, and a highlyreliable means 34.

[0058] The remote management means 32 executes the processing such asdownloading of the application 11 from the center server 1 and thedeletion after the processing has been finished.

[0059] The highly reliable means 34 records event data that occur whilethe application 11 is being executed, manages the data when a fault hasoccurred, and executes the restoration processing.

[0060] A local network 4 connects the local server 3 to equipment 5 thatare to be managed.

[0061] Next, described below is the operation of the whole system of theembodiment 1 of the invention shown in FIG. 1.

[0062] First, among the applications that have been registered in thecenter server 1, the applications 11 a to 11 x necessary for the localserver 3 are downloaded onto the local server 3 through the wide-areanetwork 2.

[0063] The downloaded applications 11 a to 11 x execute the processingsuch as controlling the equipment 5 and fetching the data in theequipment 5 that are to be managed being connected via the local network4.

[0064] Next, operation of the embodiment 1 of the invention of FIG. 1will be concretely described with reference to a flowchart of FIG. 2.

[0065] That is, described below are a mechanism of a safe and reliableoperation of a software that is downloaded and a mechanism for copingwith the abnormal condition that may occur.

[0066] Here, the network-directed software execution environment 31 thatoperates being downloaded from the center server 1 has been establishedby taking into consideration the “Java” execution environment “Java VM(Java Virtual Machine)” that has now been most widespread.

[0067] Here, it needs not be pointed out that the equivalent effect isexhibited even by those other than “Java VM”, provided they havefunctions of the same kind.

[0068] In FIG. 2, first, the application is downloaded from the centerserver 1 onto the local server 3 by the remote management means 32 inthe local server 3 (step S1).

[0069] The downloaded application 11 assumes the standby state until therequest of processing is issued from the script interpretation means 33(step S2).

[0070] Here, when a processing is requested for the application 11, whenit is judged at step S2 that the processing is requested (i.e., YES) andwhen the request of processing is input to the remote management means32, then, the application 11 starts from this moment (step S3).

[0071] Here, the script 12 corresponding to the request of processing isdownloaded onto the local server 3 from the center server 1, and thecontent of the processing is interpreted by the script interpretationmeans 33 in the local server 3.

[0072] Further, the script interpretation means 33 sends the request ofprocessing in compliance with the interpreted content of processing tothe application 11 to have it execute the processing (step S4).

[0073] Thus, the application 11 is executed via the script 12 in orderto safely and reliably execute the operation.

[0074] That is, the application 11 verifies the operation at the time ofbeing registered to the center server 1. At this moment, if theoperation of the application 11 is defined by the script 12, the rangeof operation is determined, and the operation is not executed outsidethe range described in the script 12.

[0075] Further, if all operation range is defined by the script 12, theoperation needs be verified only within the range described in thescript 12, making it possible to execute efficient and reliableverification.

[0076] Accordingly, every operation can be verified in advance toguarantee the safety in executing the application 11.

[0077] Further, since only the operation described in the script 12 isexecuted, the specification becomes clear making it possible to reliablyconfirm the required operation.

[0078] Various events are issued from the application 11 for which theprocessing is requested and which is in operation or from a system suchas OS.

[0079] Reverting to FIG. 2, the highly reliable means 34 detects anevent that is issued and records it therein as event data (step S5).

[0080] Next, the highly reliable means 34 judges whether the event thatis issued is faulty (step S6). When it is so judged that the event isfaulty (i.e., YES), not only the processing for accumulating the eventdata is executed (step S5) but also the processing is executed to copewith the fault (step S7) in compliance with a predetermined procedure,and the routine proceeds to step S8.

[0081] When it is judged at step S6 that the event is not faulty (i.e.,NO), the routine readily proceeds to step S8.

[0082] At step S8, it is judged whether the processing is all finished.When it is judged that the processing is all finished (i.e., YES), theprocessing routine of FIG. 2 ends, and the request of processing thenext application 11 is waited for.

[0083] When it is judged at step S8 that the processing has not all beenfinished (i.e., NO), the routine returns back to step S5 of recordingthe event data, and the above-mentioned processing is repeated.

[0084] Thus, the highly reliable means 34 records the event data issuedby the application 11 that is in operation (step S5), and executes anecessary countermeasure processing upon detecting abnormal condition inthe application 11 (step S7).

[0085] Owing to this function, a suitable countermeasure processing isexecuted even in case an abnormal condition occurs during the operation,and the system does not lose its function.

[0086] Embodiment 2.

[0087] The above embodiment 1 did not closely describe the remotemanagement means 32 in the local server 3. However, the remotemanagement means 32 may be constituted as shown in FIG. 3.

[0088] Described below with reference to FIG. 3 is an embodiment 2 ofthe present invention embodying the remote management means 32.

[0089]FIG. 3 is a block diagram of a constitution for concretelyillustrating the function of the remote management means 32 in the localserver 3, and wherein the same portions as those described above (seeFIG. 1) are denoted by the same reference numerals but are not describedagain.

[0090]FIG. 3 does not illustrate those constitutions that are notdirectly related to the remote management means 32, such as localnetwork 4 and equipment 5 to be managed.

[0091] In the center server 1, further, the script 12 a and theapplication 11 a only are representatively shown.

[0092] The remote management means 32 includes center server data 321,application data 322, request processing means 323, applicationdownloading means 324 and application management means 325.

[0093] The request processing means 323 responds to the request ofexecution of the application 11 issued from the script interpretationmeans 33.

[0094] The application downloading means 324 downloads the application11 from the center server 1 based upon the center server data 321 andthe application data 322.

[0095] The application management means 325 executes the processing suchas starting or deleting the application 11 based upon the applicationdata 322.

[0096] The operation of the embodiment 2 of the present invention ofFIG. 3 will now be concretely described with reference to a flowchart ofFIG. 4.

[0097] The operation of the system is the same as the one describedabove. Therefore, the following description gives attention to theprocessing operation only in the remote management means 32.

[0098] First, when the script interpretation means 33 issues the requestfor starting the application 11 a, the request for starting theapplication 11 a is input to the request processing means 323 in theremote management means 32 (step S11).

[0099] Next, it is judged whether there is the application 11 a that isto be started (step S12). When it is judged that the application 11 adoes not exist in the local server 3 (i.e., NO), the applicationdownloading means 324 receives a request from the request processingmeans 323 and makes access to the center server 1 based upon the centerserver data 321 (step S13).

[0100] Thus, the application 11 a that is to be started is downloadedfrom the center server 1 based upon the application data 322 (step S14).

[0101] The application data 322 may exist in the center server 1 insteadof in the local server 3.

[0102] In a state where the application 11 a exists in the local server3, the request processing means 323 starts the application 11 a (stepS15).

[0103] When it is judged at step S12 that the application 11 a to bestarted exists in the local server 3 (i.e., YES), the routine readilyproceeds to step S15.

[0104] After step S15, the script 12 a describing the processing of theapplication 11 a is read from the center server 1 and is sent to thescript interpretation means 33 to have the application 11 a execute theprocessing (step S16).

[0105] The actual operation of the application 11 a is executedaccording to the content of the script 12 a.

[0106] Next, it is judged whether the processing of the application 11 ahas been finished (step S17). When it is judged that the processing hasnot been completed (i.e., NO), the processing of step S16 is repeated.

[0107] When it is judged at step S17 that the processing of theapplication 11 a has been finished (i.e., YES), it is, then, judgedwhether the application is of the resident type or not (transienttype)(step S18).

[0108] When it is judged at step S18 that the application 11 a is of thetransient type (i.e., NO), the application 11 a is deleted (step S19),and the processing routine of FIG. 4 ends.

[0109] When it is judged at step S18 that the application 11 a is of theresident type (i.e., YES), the processing routine of FIG. 4 readilyends, and the application 11 a stays in the memory.

[0110] As described above, the remote management means 32 makes itpossible to efficiently download the software.

[0111] Upon deleting the transient-type application 11 after everyoperation, further, even the local server 3 having a small memorycapacity is allowed to operate the system without limited by theprocessing.

[0112] Embodiment 3.

[0113] The above embodiment 1 did not closely describe the scriptinterpretation means 33 in the local server 3. However, the scriptinterpretation means 33 may be constituted as shown in FIGS. 5 to 7.

[0114] Described below with reference to FIGS. 5 to 7 is an embodiment 3of the present invention embodying the script interpretation means 33.

[0115]FIG. 5 is a block diagram of a constitution for concretelyillustrating the function of the script interpretation means 33 in thelocal server 3, and illustrates only the peripheral constitution of thescript interpretation means 33.

[0116] The constitution that is not shown in FIG. 5 is the same as theone described above (see FIGS. 1 and 3). In FIG. 5, the scriptinterpretation means 33 includes a script definition 331, a list 332 ofevents, an interpretation means 333 and an event drive means 334.

[0117] The interpretation means 333 includes a script definition 331,interprets the script 12 according to the script definition 331, andoutputs an event corresponding to the content of the definition of thescript 12.

[0118] The event drive means 334 includes a list 332 of events, fetchesthe events, and picks up the processing driven by the event according tothe list 332 of events.

[0119]FIG. 6 is a diagram illustrating an example of the scriptdefinition 331 according to the embodiment 3 of the present invention,and FIG. 7 is a diagram illustrating a list 332 of events according tothe embodiment 3 of the present invention.

[0120] In FIG. 6, the script definition 331 stores, in the form of amap, the events corresponding to the contents of definitions in thescript 12 a and shows, for example, an event A which corresponds to thecontent of definition <script a>.

[0121] In FIG. 7, the list 332 of events is storing, in the form of amap, the applications and the processing portions corresponding to theevents and shows, for example, an application 11 a and a processingportion A corresponding to an event A.

[0122] Next, the operation of the embodiment 3 of the invention shown inFIGS. 5 to 7 will be described with reference to a flowchart of FIG. 8.

[0123] The following description gives attention to only the processingof the script interpretation means 33.

[0124] First, due to the interposition of the remote management means 32(see FIGS. 1 and 3), the local server 3 reads the script 12 a in thecenter server 1 into the interpretation means 333 in the scriptinterpretation means 33 (step S21).

[0125] Next, the interpretation means 333 picks up the event Acorresponding to the content of definition <script a>according to thescript definition 331 (step S22).

[0126] Then, the event drive means 334 picks up the processing(application 11 a, processing A) corresponding to the event A accordingto the list 332 of events (step S23) and requests the application 11 ato execute the processing (step S24).

[0127] As a result, the script interpretation means 33 flexibly definesthe specifications of the script 12 for safely and reliably executingthe processing.

[0128] That is, owing to the script definition 331, the script 12 can bedefined in a form independent from the processing.

[0129] The script 12 itself can be so specified as to define the puremeaning of the processing without limited by the specifications of thenetwork constituting the system, hardware and software.

[0130] The script definition 331 crosslinks the script 12 that ismeaningfully specified with the real system, and defines thecorrespondence between the description in the script 12 and the eventbased on the specifications of the system.

[0131] On the other hand, the list 332 of events crosslinks the eventbased on the specifications of the system with the mounting of thesoftware that really operates, expands the degree of freedom indesigning the software relying on the above-mentioned constitution, andmakes it possible to freely fabricate the constitution of the softwarecorresponding to a given event.

[0132] For a local server 3 having a small memory capacity, for example,a software that uses less memory is mounted. For a local server 3 forwhich the processing speed is demanded rather than warrying about thelimitation on the memory capacity, on the other hand, a software whichgives importance to performance is mounted.

[0133] The mounting can be easily sorted by simply changing the list ofevents 332 in the local server 3.

[0134] Embodiment 4.

[0135] The above embodiment 3 did not closely describe the form ofdescription of the script 12 and of the script definition 331. They,however, may be described in a manner as shown in FIGS. 9 and 10.

[0136] Described below with reference to FIGS. 9 and 10 is an embodiment4 of the present invention embodying the form of describing the script12 and the script definition 331.

[0137]FIGS. 9 and 10 are diagrams illustrating the description ofservices of the script 12 and the script definition 331.

[0138] In FIG. 9, the script 12 handled in the script interpretationmeans 33 (see FIG. 5) is described in XML (extensible markup language).

[0139] In FIG. 10, the script definition 331 in the interpretation means333 is described in DTD (document type definition) to correspond to theXML document.

[0140] When the script 12 describing the operation of the application 11is given by the XML as shown in FIG. 9, a general-purpose XML parser isused in the script interpretation means 33.

[0141] In this case, use of SAX (simple API for XML) which is a standardspecification of the parser makes it possible to pick up events such asstart and end of a tag.

[0142] In the case of the air conditioner control service described asshown in FIGS. 9 and 10, events are successively picked up, such asstart of air conditioner control, start of initialization, start of airconditioner initialization, setting of temperature, setting of the windvelocity, end of air conditioner initialization, start of temperaturesensor initialization - - - .

[0143] Further, the event drive means 334 in the script interpretationmeans 33 executes the corresponding processing based upon the list ofevents 332.

[0144] Upon defining the tag of XML for every event that occurs, asdescribed above, it is allowed to pick up the event from the script 12(XML document) by using a standard XML parser.

[0145] By describing the script definition 331 in the interpretationmeans 333 in the DTD form (see FIG. 10) corresponding to XML, further,correctness of the XML document (script 12) can be verified based on thefunction of the XML parser.

[0146] That is, upon verifying the DTD, it is allowed to guarantee thatthe script 12 has been correctly described.

[0147] Embodiment 5.

[0148] The above embodiment 1 has closely described neither the faultcountermeasure means 13 in the center server 1 nor the highly reliablemeans 34 in the local server 3. However, the fault countermeasure means13 and the highly reliable means 34 may be constituted as shown in FIG.11.

[0149] Described below with reference to FIG. 11 is an embodiment 5 ofthe present invention embodying the fault countermeasure means 13 andthe highly reliable means 34.

[0150]FIG. 11 is a block diagram of a constitution for concretelyillustrating the functions of the fault countermeasure means 13 and thehighly reliable means 34, and wherein the constitution that is not shownis the same as the one described above (see FIG. 1).

[0151] In FIG. 11, the fault countermeasure means 13 includes a faultdata-obtaining means 131 for obtaining data related to a fault that hasoccurred from the local server 3, and a fault countermeasure-notifyingmeans 132 for determining the countermeasure against the fault that hasoccurred and for notifying the fault countermeasure to the local server3.

[0152] The highly reliable means 34 includes fault data 341, event data342, a fault detector means 343, a fault data collection means 344, afault-notifying means 345, a restoration means 346 and an eventcollection means 347.

[0153] The fault detector means 343 detects the occurrence of fault, thefault data collection means 344 collects the fault data 341 of whenfault has occurred, and the fault-notifying means 345 informs the centerserver 1 of the fault data 341.

[0154] The restoration means 346 restores the fault in response to thefault countermeasure from the center server 1.

[0155] The event collection means 347 collects and records the eventdata 342.

[0156] Next, the operation of the embodiment 5 of the invention will bedescribed with reference to a flowchart of FIG. 12.

[0157] The following description gives attention to the cooperationprocessing of the fault countermeasure means 13 in the center server 1and the highly reliable means 34 in the local server 3.

[0158] In FIG. 12, first, when an event occurs from the application 11or the system (OS in the local server 3, etc.) (step S31), the eventcollection means 347 in the highly reliable means 34 collects the eventthat has occurred and judges whether the event is the one related to thefault (step S32).

[0159] When it is judged at step S32 that the event that is collected isa normal event which is not related to the fault (not the event underthe abnormal condition)(i.e., NO), the event is recorded as event data342 (step S33), and the processing routine of FIG. 12 ends.

[0160] On the other hand, when it is judged at step S32 that the eventthat is collected is related to the fault (event under the abnormalcondition)(i.e., YES), the fault detector means 343 is informed of theoccurrence of the fault (step S34).

[0161] The fault detector means 343 examines the event of under abnormalcondition, specifies the kind of the fault (fault data), starts thefault data collection means 344 and stores the event as fault data 341(step S35).

[0162] The thus detected fault data 341 is then sent to the centerserver 1 via the fault-notifying means 345 (step S36).

[0163] In response thereto, the fault countermeasure means 13 in thecenter server 1 executes the following processing.

[0164] That is, the fault data-obtaining means 131 receives fault data341 from the local server 3, and the fault countermeasure-notifyingmeans determines a suitable countermeasure against the fault data 341and sends it to the local server 3 (step S37).

[0165] In response thereto, the highly reliable means 34 in the localserver 3 executes the processing by the restoration means 346. That is,the operation for restoration from the fault is executed based on thecountermeasure sent from the center server 1 (step S38), and theprocessing routine of FIG. 12 ends.

[0166] Thus, owing to the cooperation processing between the faultcountermeasure means 13 in the center server 1 and the highly reliablemeans 34 in the local server 3, it is allowed to prevent the wholesystem from malfunctioning despite an abnormal condition has occurred.

[0167] Further, the fault data 341 and the event data 342 stored as logsin the local server 3 can be utilized for the subsequent system analysisand the like. Even in case the system as a whole comes into a halt, theanalysis can be smoothly conducted.

[0168] The fault data 341 is sent to the center server 1 and may, hence,be stored in the center server 1 instead of in the local server 3.

[0169] Embodiment 6.

[0170] The above embodiment 5 did not closely describe the faultcountermeasure-notifying means 132 in the fault countermeasure means 13.However, the fault countermeasure-notifying means 132 may be constitutedas shown in FIG. 13.

[0171] Described below with reference to FIG. 13 is an embodiment 6 ofthe present invention embodying the fault countermeasure-notifying means132 in the fault countermeasure means 13.

[0172]FIG. 13 is a block diagram of a constitution for concretelyillustrating the function of the fault countermeasure-notifying means132, and wherein the constitution that is not shown is the same as theconstitution described above (see FIGS. 1 and 11).

[0173] In FIG. 13, the fault countermeasure means 13 in the centerserver 1 is provided with a list 133 of countermeasures against thefault in addition to the above-mentioned fault data-obtaining means 131and the fault countermeasure-notifying means 132.

[0174] The list 133 of countermeasures against fault stores, in the formof a map, the countermeasures against fault for each of the kinds offault data in a manner that the kinds of the fault data are correspondedto the countermeasures against fault.

[0175] The fault countermeasure-notifying means 132 includes the faultcountermeasure detector means 1321 and the notifying means 1322.

[0176] The fault countermeasure detector means 1321 detects thecountermeasure system corresponding to the kind of the fault data basedupon the list 133 of countermeasures against fault.

[0177] The notifying means 1322 informs the local server 3 of thecountermeasure against fault obtained from the list 133 ofcountermeasures against fault.

[0178] Next, the operation of the embodiment 6 of the invention will bedescribed with reference to a flowchart of FIG. 14.

[0179] The following description gives attention to the faultcountermeasure processing in the center server 1.

[0180] In FIG. 14, the processings at steps S36 and S38 are the same asthose described above (see FIG. 12), and the processings at steps S31 toS35 that are not shown in FIG. 14 are the same as those of FIG. 12.

[0181] When a fault occurs in the local server 3, fault data (kind) issent to the center server 1 through the fault-notifying means 345 asdescribed above (step S36).

[0182] The fault data-obtaining means 131 in the center server 1receives fault data from the local server 3 (step S371) and hands itover to the fault countermeasure detector means 1321 in the faultcountermeasure-notifying means 132.

[0183] The fault countermeasure detector means 1321 detects thecountermeasure corresponding to the kind of the fault data that is sentbased upon the list 133 of countermeasures against fault (step S372).

[0184] Then, the countermeasure-notifying means 1322 transmits thedetected countermeasure against fault to the restoration means 346 inthe local server 3 (step S373).

[0185] Then, the restoration means 346 executes the processingcorresponding to the countermeasure against fault (step S38).

[0186] Thus, the fault countermeasure means 13 in the center server 1 isprovided with the fault countermeasure detector means 1321 that worksbased on the list 133 of countermeasures against fault, facilitating thedesigning to cope with fault in advance and guaranteeing safety of thewhole system.

[0187] The list 133 of the countermeasures against fault can be updatedin real time and can readily be reflected in the system when the kindsof fault data are newly increased or when it is demanded to employ moreefficient countermeasures against fault.

[0188] Embodiment 7.

[0189] In the above-mentioned embodiments 5 and 6, the faultcountermeasure means 13 in the center server 1 was provided with thefault countermeasure-notifying means 132, and the local server 3 wasinformed of the countermeasure corresponding to the kind of fault data.However, the highly reliable means 34 in the local server 3 mayautonomously execute the countermeasures against fault.

[0190] Described below with reference to FIG. 15 is an embodiment 7 ofthe present invention which autonomously executes the countermeasureagainst fault in the highly reliable means 34.

[0191]FIG. 15 is a block diagram of a constitution for concretelyillustrating the function of the highly reliable means 34, wherein thesame portions as those described above (see FIGS. 1, 11 and 13) aredenoted by the same reference numerals but are not described here again.

[0192] In FIG. 15, the fault countermeasure means 13 in the centerserver 1 has the fault data-obtaining means 131 but does not have theabove-mentioned fault countermeasure-notifying means 132 (see FIGS. 11and 13).

[0193] The highly reliable means 34 in the local server 3 includes theabove-mentioned fault data 341, event data 342, fault detector means343, fault data collection means 344, event collection means 347, aswell as restoration means 348 and notifying means 349.

[0194] The restoration means 348 autonomously copes with the fault thathas occurred to restore from the fault.

[0195] The notifying means 349 informs the fault data-obtaining means131 in the center server 1 of the fault data 341 and of the data relatedto automatic restoration.

[0196] Next, the operation of the highly reliable means 34 according tothe embodiment 7 of the present invention will be described withreference to a flowchart of FIG. 16.

[0197] In FIG. 12, steps S31 to S35 are the same processings as thosedescribed above (see FIG. 12).

[0198] In this case, the processings are the same as those describedabove from the occurrence of event (step S31) through up to thecollection of fault data (step S35).

[0199] Hereinafter, the highly reliable means 34 in the local server 3does not inform the center server 1 of the fault data but completes theautomatic restoration processing for the fault in the local server 3(step S39).

[0200] Finally, the fault data-obtaining means 131 in the center server1 is informed of only the fault data 341 and the result of automaticrestoration (step S40), and the processing routine of FIG. 16 ends.

[0201] This simplifies the functional constitution of the faultcountermeasure means 13 in the center server 1, and the notifyingprocessing (step S40) needs be effected only once for informing thecenter server 1 of the fault data 341 and the fault countermeasure fromthe local server 3, reducing the amount of communication that flows intothe wide-area network 2.

[0202] At the occurrence of fault, further, the restoration is readilycompleted in the local server 3 making it possible to shorten the timefor coping with the fault.

[0203] This system for coping with the fault is effective for executingsimple processing, such as when the degree of fault is very small, whenthe faulty application 11 needs simply be re-started, etc.

[0204] In the case of the fault that requires complex processing,therefore, the system for coping with the fault of the embodiment 5 or 6can often be effectively utilized.

[0205] Embodiment 8.

[0206] Though none of the embodiments 1 to 7 have referred to the numberof the local servers 3 connected to the center server 1, plural localservers 3 may be connected to the center server 1.

[0207] An embodiment 8 of the present invention in which plural localservers 3 are connected to the center server 1 will now be describedwith reference to FIG. 17.

[0208]FIG. 17 is a block diagram of the constitution illustrating theembodiment 8 of the present invention, wherein the same portions asthose described above (see FIG. 1) are denoted by the same referencenumerals but are not described again.

[0209] In FIG. 17, local servers 3 a to 3 n of a number of, for example,n are connected to the center server 1.

[0210] Equipment 5 a to 5 n that are to be managed are connected to thelocal servers 3 a to 3 n of the same constitution via local networks 4 ato 4 n, respectively.

[0211] Even in a system where there exist plural local servers 3 a to 3n as shown in FIG. 17, the center server 1, in theory, needs be employedin a number of only one. In this case, too, the basic operation is thesame as the one described above, exhibiting the action and effect sameas those described above.

[0212] In a large-scale network-directed software distribution system,too, therefore, the reliability can be improved in the same manner asdescribed above.

[0213] Depending upon the scale of the system, the number of the centerservers 1 may be increased to meet the scale of the system in order todecrease the burden exerted on each center server 1.

[0214] When plural center servers 1 are provided, redundancy can beimparted to the center server function. Even in case any center serverbreaks down, therefore, other center servers work to back up,maintaining improved reliability.

[0215] Embodiment 9.

[0216] In the above-mentioned embodiment 1, the center server 1 isprovided with the fault countermeasure means 13 and the local server 3is provided with the highly reliable means 34. Here, however, the faultcountermeasure means 13 and the highly reliable means 34 may be omitted.

[0217] Described below with reference to FIG. 18 is an embodiment 9 ofthe present invention omitting the fault countermeasure means 13 and thehighly reliable means 34.

[0218]FIG. 18 is a block diagram of a constitution illustrating theembodiment 9 of the present invention, wherein the same portions asthose described above (see FIG. 1) are denoted by the same referencenumerals but are not described here again.

[0219] Therefore, the operation of the embodiment 9 of the inventionshown in FIG. 18 is the same as that of the above-mentioned flowchart(see FIG. 2) from which are deleted steps S5 to S8 that are related tothe fault countermeasure means 13 and the highly reliable means 34.

[0220] In this case, the software operating in the local server 3 can bevery simplified.

[0221] The constitution of FIG. 18 is effective when the reliability canbe maintained to a sufficient degree relying only upon the controloperation by the script 12.

[0222] Thus, the software constitution of the local server 3 issimplified, and a highly reliable processing is realized even by usingthe local server 3 having a small memory capacity.

[0223] Embodiment 10.

[0224] Though the above-mentioned embodiment 9 did not refer to thenumber of the local servers 3 connected to the center server 1, plurallocal servers 3 may be connected to the center server 1 like in theabove-mentioned embodiment 8.

[0225] An embodiment 10 of the invention in which plural local servers 3are connected to the center server 1 will now be described withreference to FIG. 19.

[0226] In FIG. 19, plural local servers 3 a to 3 n are connected to thecenter server 1.

[0227] Even in a system having plural local servers 3 a to 3 n as shownin FIG. 19, the center server 1, in theory, needs be employed in anumber of only one, and the basic operation is the same as describedabove.

[0228] This makes it possible to improve the reliability even in alarge-scale network-directed software distribution system in which thereexist plural local servers 3 that execute simple processings.

[0229] Embodiment 11.

[0230] In the above-mentioned embodiment 8 (see FIG. 17), the localservers 3 a to 3 n connected to the center server 1 are all providedwith highly reliable means 34 a to 34 n. However, only some of the localservers 3 may be provided with the highly reliable means 34, and thehighly reliable means 34 may be omitted from other local servers 3.

[0231] Described below with reference to FIG. 20 is an embodiment 11 ofthe present invention in which only some of the plural local servers 3are provided with the highly reliable means 34.

[0232]FIG. 20 is a block diagram of a constitution illustrating theembodiment 11 of the present invention, wherein the same portions asthose described above (see FIG. 17) are denoted by the same referencenumerals but are not described here again.

[0233] Among plural local servers 3 a to 3 n in FIG. 20, some localservers 3 a are not equipped with the highly reliable means 34 but otherlocal servers 3 n are equipped with the highly reliable means 34 n.

[0234] The basic operation of the embodiment 11 of the invention shownin FIG. 20 is the same as the one described above in connection with thelocal servers 3 a to 3 n.

[0235] The constitution of FIG. 20 is effective in a system whichcontains local servers 3 n that require the highly reliable means 34 nand local servers 3 a that do not require the highly reliable means 34.

[0236] In this case, too, the center server 1 equipped with the faultcountermeasure means 13 may, in theory, be provided in a number of onlyone, and the basic operation is the same as the one described above.Further, the number of the center servers 1 may be increased with anincrease in the scale of the system.

[0237] Thus, it is allowed to improve reliability of even a large-scalenetwork-directed software distribution system which contains localservers 3 a for executing simple processings and local servers 3 n forexecute normal highly reliable processings.

[0238] Embodiment 12.

[0239] In the above-mentioned embodiment 1, the center server 1 wasprovided with the script 12, and the local server 3 was provided withthe script interpretation means 33. However, the script 12 and thescript interpretation means 33 may be omitted.

[0240] This can be effectively employed for a simple system thatoperates with the application 11 only, and the constitutions of thecenter server 1 and the local servers 3 can be simplified.

[0241] In case a fault occurs, the countermeasure exhibits the sameaction and effect as those described above.

[0242] This can be further applied to a system in which plural localservers 3 are connected to the center server 1.

1. A software management system comprising a network system whichincludes a center server and a local server connected to said centerserver via a wide-area network, wherein: said center server includes; anapplication that operates upon being downloaded onto said local server;a script describing the operation of said application; and a faultcountermeasure means for coping with the occurrence of a fault; and saidlocal server includes: a network-directed language executionenvironment; a remote management means for downloading the applicationfrom said center server, and for deleting the application after theprocessing has been finished; a script interpretation means forinterpreting the script and for requesting said application to executethe processing; and a highly reliable means for recording event datathat occur while said application is being executed, for managing thedata when the fault has occurred, and for executing the restorationprocessing.
 2. A software management system according to claim 1,wherein said remote management means includes: center server data andapplication data; a request processing means that works in response to arequest for executing said application; an application downloading meansfor downloading the application from said center server based upon saidcenter server data and said application data; and an applicationmanagement means for executing the processing for driving or deletingsaid application based on said application data.
 3. A softwaremanagement system according to claim 1, wherein said scriptinterpretation means includes: a script definition and a list of events;an interpretation means for interpreting said script in accordance withsaid script definition and for outputting an event corresponding to thecontent of definition of said script; and an event drive means forfetching said event and for picking up a processing that is driven bysaid event according to said list of events.
 4. A software managementsystem according to claim 1, wherein said script is described in XML(extensible markup language), and the script definition is described inDTD (document type definition).
 5. A software management systemaccording to claim 1, wherein said fault countermeasure means includes:a fault data-obtaining means for obtaining fault data from said localserver in case fault has occurred; and a fault countermeasure-notifyingmeans for determining the countermeasure against the fault in case thefault has occurred and for notifying it to said local server; and saidhighly reliable means includes: a fault detector means for detecting theoccurrence of a fault that has occurred; a fault data correction meansfor correcting the fault data when the fault has occurred; afault-notifying means for notifying said fault data to said centerserver; a restoration means for restoring the fault relying upon thecountermeasure against the fault from said center server; and an eventcollection means for correcting and recording said event data.
 6. Asoftware management system according to claim 5, wherein said faultcountermeasure means includes: a list of fault countermeasures, storingcountermeasures against faults for each of the kinds of the fault data;and said fault countermeasure-notifying means includes: a faultcountermeasure detector means for detecting a countermeasure againstfault corresponding to the kind of the fault data based upon a list ofthe fault countermeasures; and a notifying means for notifying thecountermeasure against fault to said local server.
 7. A softwaremanagement system according to claim 1, wherein said faultcountermeasure means includes: a fault data-obtaining means forobtaining fault data of when the fault has occurred from said localserver; and said highly reliable means includes: a fault detector meansfor detecting the occurrence of a fault; a fault data collection meansfor collecting fault data of when the fault has occurred; a restorationmeans for autonomously coping with the occurrence of a fault toautomatically restore the fault; a notifying means for notifying thefault data and the data of automatic restoration to said center server;and an event collection means for collecting and recording the eventdata.
 8. A software management system according to claim 1, wherein saidlocal servers exist in a plural number, each of which including saidnetwork-directed language execution environment, said remote managementmeans, said script interpretation means and said highly reliable means.9. A software management system according to claim 8, wherein saidcenter servers exist in a plural number, each of which including saidapplication, said script and said fault countermeasure means.
 10. Asoftware management system according to claim 1, wherein said localservers exist in a plural number, at least one of which including saidnetwork-directed language execution environment, said remote managementmeans, said script interpretation means and said highly reliable means,and other local servers including said network-directed languageexecution environment, said remote management means and said scriptinterpretation means.
 11. A software management system comprising anetwork system which includes a center server and a local serverconnected to said center server via a wide-area network, wherein: saidcenter server includes; an application that operates upon beingdownloaded onto said local server; and a script describing the operationof said application; and said local server includes: a network-directedlanguage execution environment; a remote management means fordownloading the application from said center server, and for deletingthe application after the processing has been finished; and a scriptinterpretation means for interpreting the script and for requesting saidapplication to execute the processing.
 12. A software management systemaccording to claim 11, wherein said local servers exist in a pluralnumber, each of which including said network-directed language executionenvironment, said remote management means and said script interpretationmeans.
 13. A software management system comprising a network systemwhich includes a center server and a local server connected to saidcenter server via a wide-area network, wherein: said center serverincludes; an application that operates upon being downloaded onto saidlocal server; and a fault countermeasure means for coping with theoccurrence of a fault; and said local server includes: anetwork-directed language execution environment; a remote managementmeans for downloading the application from said center server, and fordeleting the application after the processing has been finished; and ahighly reliable means for recording event data that occur while saidapplication is being executed, for managing the data when the fault hasoccurred, and for executing the restoration processing.
 14. A softwaremanagement system according to claim 13, wherein said local serversexist in a plural number, each of which including said network-directedlanguage execution environment, said remote management means and saidhighly reliable means.